Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@internal/repository/feedback_records_repository.go`:
- Around line 245-314: List and ListAfterCursor duplicate the SELECT statement
and the rows.Scan loop which risks drift; extract a shared helper such as
fetchFeedbackRecords(ctx, query string, args ...interface{})
([]models.FeedbackRecord, error) or split into buildBaseSelect() string plus
scanRowsToFeedbackRecords(rows pgx.Rows) ([]models.FeedbackRecord, error). Move
the SELECT column list into the shared buildBaseSelect or use it inside the
helper, have both List and ListAfterCursor call the helper (pass the assembled
WHERE/LIMIT parts and args), and ensure the helper handles query execution, rows
iteration, scanning into models.FeedbackRecord, error wrapping, and rows.Close
to preserve existing behavior.

In `@internal/service/feedback_records_service.go`:
- Around line 168-188: Extract the duplicated pagination assembly into a shared
helper to avoid repeating the same pointer/next-cursor logic used in
ListFeedbackRecords (internal/service/feedback_records_service.go) and
ListWebhooks (internal/service/webhooks_service.go): create a helper (e.g.,
buildPaginatedMeta or buildPaginationResponse) that accepts the records slice,
total (int), filters (with Limit and Offset), and a cursor encoder function
(cursor.Encode) and returns the computed Total *int, Limit int, Offset *int, and
NextCursor string (or a small struct with those fields); then call this helper
from ListFeedbackRecords and ListWebhooks to populate
models.ListFeedbackRecordsResponse and the webhooks response type respectively,
keeping the existing error handling for cursor.Encode in the helper.

In `@openapi.yaml`:
- Around line 158-165: Add an explicit 400 response for invalid cursor on the
list endpoints that accept the query parameter named "cursor" (e.g., the
/v1/feedback-records and /v1/webhooks paths) so generated clients can surface
cursor validation errors; update each operation object to include a 400 response
entry with a clear description like "Invalid cursor" and a response schema
matching your existing error model (reuse the same error schema used by other
400 responses in the spec) to keep the OpenAPI contract aligned with runtime
behavior.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@internal/repository/webhooks_repository.go`:
- Around line 149-185: The List and ListAfterCursor methods duplicate query
execution and row-to-model mapping; extract the shared logic into a single
helper such as fetchWebhooks or scanWebhooksRows that accepts ctx, query and
args (and returns ([]models.Webhook, error)), centralizes rows scanning
(including scanning into dbEventTypes, calling parseDBEventTypes, and mapping
fields
ID/URL/SigningKey/Enabled/TenantID/CreatedAt/UpdatedAt/DisabledReason/DisabledAt),
closes rows and checks rows.Err(), and is called by both List and
ListAfterCursor to avoid drift when selected columns change.

In `@internal/service/feedback_records_service.go`:
- Around line 121-126: The code dereferences the filters parameter
(filters.Limit and filters.Cursor) without a nil check; add a defensive nil
guard at the start of the function that owns this code in
internal/service/feedback_records_service.go: if filters == nil, initialize a
default filters value (or assign a local default struct) before using it so the
subsequent logic that sets filters.Limit (default 100) and uses
strings.TrimSpace(filters.Cursor) cannot panic; ensure the rest of the function
uses that non-nil filters variable.

In `@internal/service/pagination.go`:
- Around line 11-26: BuildListPaginationMeta currently treats recordCount==limit
as "more pages" which causes a spurious NextCursor when the final page contains
exactly limit items; to fix, change the callers (e.g., the repository methods
such as in webhooks_repository.go) to fetch limit+1 rows as a sentinel, trim the
returned results down to limit before returning, and pass the full fetched count
into BuildListPaginationMeta; then update BuildListPaginationMeta usage to only
emit NextCursor when recordCount > limit (i.e., a true extra item was fetched)
and keep meta.Limit as the original limit. Ensure encodeLast() is only called
when recordCount > limit and repositories drop the extra item before returning
the result set.

In `@migrations/006_list_keyset_indexes.sql`:
- Around line 1-21: Do not modify migrations/006_list_keyset_indexes.sql;
instead create a new sequential migration file (e.g.,
007_keyset_pagination_indexes.sql) containing the same DDL changes (the
CONCURRENTLY DROP/CREATE for idx_feedback_records_tenant_collected_at_id,
idx_webhooks_tenant_created_at_id and recreation of
idx_feedback_records_tenant_collected_at in the Down), include the same goose
headers (+goose Up and +goose Down and NO TRANSACTION), and leave migration 006
unchanged so environments that already ran 006 will receive these index
operations via the new migration.